Hi,
We're stuck at version DOORS 6.0. We didn't use few years properly. We heard DOORS 8.3 is working good. Could anyone tell me, Is it possible to migrate the data directly from DOORS 6.0 to 8.3?
Thanks!
SystemAdmin - Wed Mar 11 10:33:00 EDT 2009 |
|
Re: Migrate data from DOORS 6.0 to 8.3 Peter_Albert - Wed Mar 11 11:17:15 EDT 2009
No, it is not. Migrating always works for one step in major version number. You have to migrate from 6.0 to 7.1 and then to 8.3
Regards,
Peter
|
|
Re: Migrate data from DOORS 6.0 to 8.3 llandale - Wed Mar 11 11:21:31 EDT 2009
I'm pretty sure the database must first be migrated to v7, then to v8.
Coordinating getting all the clients upgraded to the new version is by far the most difficult part of migrating DOORS; adding a temporary v7 service and client on the DOORS server and migrating the actual data to that, and immediately to v8 is not very tricky; and doesn't require any of the client computers to get v7 installed.
>>>>>> preparation
>>Install v7 service and client on DOORS server, assigning temporary 'port' which does not need to be poked through the fire wall.
>>Install v8 service and client on DOORS server, assigning permanent 'port' which yes needs to be poked through the fire wall.
>>Start v7 Service, then DOORS client on Server, make sure it initializes the database.
>>Start v8 Service, then DOORS client on Server, make sure it initializes the database OK.
>>On some test Client, install DOORS 8 and make sure it can see the empty v8 database.
>>Export the v6 user database, import it into the v8 database.
>>Put some module in the v8 database telling folks v8 is coming, but continue to use v6 as live database.
>>Start installing v8 on all the clients.
>>>>> on the migrate week-end.
>>Turn off the v7 service. Delete the entire v7 database folder hierarchy.
>>Turn off the v8 service. Delete the entire v8 database folder hierarchy.
>>Export the v6 user directory; hold it for a step below.
>>Kick off all v6 users.
>>Turn off the v6 service.
>>Copy the entire v6 database folder hierarchy to the v7 folder location.
>>Start the v7 Service. Start v7 client logging in as the 'Administrator' using the v6 Administrator password. Confirm migrating the database to v7.
>>Logout v7, stop the v7 service.
>>Copy the entire v7 database folder hierarchy to the v8 folder location.
>>Start the v8 Service. Start v8 client logging in as the 'Administrator'. Confirm migrating the database to v8.
>>Start some v8 client to make sure you can see the database from a Client.
>>Copy/move the v6 database hierarchy to some permanant backup location.
>>Erase the v6 database hierarchy.
>>Start the v6 service. Start the v6 client, confirming initializing a new database.
>>Import the previously exported v6 user directory to the new v6 database.
>>Put some flag or module in the v6 database telling folks that this database is dead, and they should use v8 as the live database.
>>Let users log in.
Notice that when you initiatize a new database you must provide an Administrator password that may not be the same as the production database. However, since we are purging temp databases and restoring user databases, the 'Administrator' password will tend to be the live one. To prevent any confusion, be sure to specify the current live 'Administrator' password when initializing a new database.
The hard part is getting v8 installed on the clients. We do that a week in advance, providing info in the v8 database to continue using the v6 live database. After the migrate week end, folks who use v6 will see the module telling them to use v8 live, along with instructions for getting v8 installed if not already. IT has some mechanism for querying clients to make sure that everyone who has v6 will get v8 installed.
After a week or so, remove v6 from all the clients and turn off and delete the v6 service. Delete the v7 service and database hierarchy folder.
There are some problems, such as installing v8 will uninstall v6; in which case your v8 install must reinstate the v6 install. Be SURE to stop the Services before doing any folder copying/moving.
v8 also requires new licensing, which you would deal with before the migrate weekend.
>Louie
|
|
Re: Migrate data from DOORS 6.0 to 8.3 llandale - Wed Mar 11 11:33:18 EDT 2009 llandale - Wed Mar 11 11:21:31 EDT 2009
I'm pretty sure the database must first be migrated to v7, then to v8.
Coordinating getting all the clients upgraded to the new version is by far the most difficult part of migrating DOORS; adding a temporary v7 service and client on the DOORS server and migrating the actual data to that, and immediately to v8 is not very tricky; and doesn't require any of the client computers to get v7 installed.
>>>>>> preparation
>>Install v7 service and client on DOORS server, assigning temporary 'port' which does not need to be poked through the fire wall.
>>Install v8 service and client on DOORS server, assigning permanent 'port' which yes needs to be poked through the fire wall.
>>Start v7 Service, then DOORS client on Server, make sure it initializes the database.
>>Start v8 Service, then DOORS client on Server, make sure it initializes the database OK.
>>On some test Client, install DOORS 8 and make sure it can see the empty v8 database.
>>Export the v6 user database, import it into the v8 database.
>>Put some module in the v8 database telling folks v8 is coming, but continue to use v6 as live database.
>>Start installing v8 on all the clients.
>>>>> on the migrate week-end.
>>Turn off the v7 service. Delete the entire v7 database folder hierarchy.
>>Turn off the v8 service. Delete the entire v8 database folder hierarchy.
>>Export the v6 user directory; hold it for a step below.
>>Kick off all v6 users.
>>Turn off the v6 service.
>>Copy the entire v6 database folder hierarchy to the v7 folder location.
>>Start the v7 Service. Start v7 client logging in as the 'Administrator' using the v6 Administrator password. Confirm migrating the database to v7.
>>Logout v7, stop the v7 service.
>>Copy the entire v7 database folder hierarchy to the v8 folder location.
>>Start the v8 Service. Start v8 client logging in as the 'Administrator'. Confirm migrating the database to v8.
>>Start some v8 client to make sure you can see the database from a Client.
>>Copy/move the v6 database hierarchy to some permanant backup location.
>>Erase the v6 database hierarchy.
>>Start the v6 service. Start the v6 client, confirming initializing a new database.
>>Import the previously exported v6 user directory to the new v6 database.
>>Put some flag or module in the v6 database telling folks that this database is dead, and they should use v8 as the live database.
>>Let users log in.
Notice that when you initiatize a new database you must provide an Administrator password that may not be the same as the production database. However, since we are purging temp databases and restoring user databases, the 'Administrator' password will tend to be the live one. To prevent any confusion, be sure to specify the current live 'Administrator' password when initializing a new database.
The hard part is getting v8 installed on the clients. We do that a week in advance, providing info in the v8 database to continue using the v6 live database. After the migrate week end, folks who use v6 will see the module telling them to use v8 live, along with instructions for getting v8 installed if not already. IT has some mechanism for querying clients to make sure that everyone who has v6 will get v8 installed.
After a week or so, remove v6 from all the clients and turn off and delete the v6 service. Delete the v7 service and database hierarchy folder.
There are some problems, such as installing v8 will uninstall v6; in which case your v8 install must reinstate the v6 install. Be SURE to stop the Services before doing any folder copying/moving.
v8 also requires new licensing, which you would deal with before the migrate weekend.
>Louie
.... and turn off and delete the v7 service and delete the v7 database hierarchy and uninstall v7 from the server. And turn off and delete the v6 service and delete the v6 database hierarchy and uninstall v6 from the server.
|
|
Re: Migrate data from DOORS 6.0 to 8.3 SystemAdmin - Wed Mar 11 11:55:55 EDT 2009
I would appreciate lot, if someone could help me out. I heared that we need to migrate to DOORS 7.1 then only we can migrate to DOORS 8.3. Is that true?
Regards,
Raj
|
|
Re: Migrate data from DOORS 6.0 to 8.3 SystemAdmin - Wed Mar 11 11:59:34 EDT 2009 SystemAdmin - Wed Mar 11 11:55:55 EDT 2009
I would appreciate lot, if someone could help me out. I heared that we need to migrate to DOORS 7.1 then only we can migrate to DOORS 8.3. Is that true?
Regards,
Raj
Please ignore my earlier message. Thanks!
|
|
Re: Migrate data from DOORS 6.0 to 8.3 SystemAdmin - Wed Mar 11 12:09:59 EDT 2009 llandale - Wed Mar 11 11:21:31 EDT 2009
I'm pretty sure the database must first be migrated to v7, then to v8.
Coordinating getting all the clients upgraded to the new version is by far the most difficult part of migrating DOORS; adding a temporary v7 service and client on the DOORS server and migrating the actual data to that, and immediately to v8 is not very tricky; and doesn't require any of the client computers to get v7 installed.
>>>>>> preparation
>>Install v7 service and client on DOORS server, assigning temporary 'port' which does not need to be poked through the fire wall.
>>Install v8 service and client on DOORS server, assigning permanent 'port' which yes needs to be poked through the fire wall.
>>Start v7 Service, then DOORS client on Server, make sure it initializes the database.
>>Start v8 Service, then DOORS client on Server, make sure it initializes the database OK.
>>On some test Client, install DOORS 8 and make sure it can see the empty v8 database.
>>Export the v6 user database, import it into the v8 database.
>>Put some module in the v8 database telling folks v8 is coming, but continue to use v6 as live database.
>>Start installing v8 on all the clients.
>>>>> on the migrate week-end.
>>Turn off the v7 service. Delete the entire v7 database folder hierarchy.
>>Turn off the v8 service. Delete the entire v8 database folder hierarchy.
>>Export the v6 user directory; hold it for a step below.
>>Kick off all v6 users.
>>Turn off the v6 service.
>>Copy the entire v6 database folder hierarchy to the v7 folder location.
>>Start the v7 Service. Start v7 client logging in as the 'Administrator' using the v6 Administrator password. Confirm migrating the database to v7.
>>Logout v7, stop the v7 service.
>>Copy the entire v7 database folder hierarchy to the v8 folder location.
>>Start the v8 Service. Start v8 client logging in as the 'Administrator'. Confirm migrating the database to v8.
>>Start some v8 client to make sure you can see the database from a Client.
>>Copy/move the v6 database hierarchy to some permanant backup location.
>>Erase the v6 database hierarchy.
>>Start the v6 service. Start the v6 client, confirming initializing a new database.
>>Import the previously exported v6 user directory to the new v6 database.
>>Put some flag or module in the v6 database telling folks that this database is dead, and they should use v8 as the live database.
>>Let users log in.
Notice that when you initiatize a new database you must provide an Administrator password that may not be the same as the production database. However, since we are purging temp databases and restoring user databases, the 'Administrator' password will tend to be the live one. To prevent any confusion, be sure to specify the current live 'Administrator' password when initializing a new database.
The hard part is getting v8 installed on the clients. We do that a week in advance, providing info in the v8 database to continue using the v6 live database. After the migrate week end, folks who use v6 will see the module telling them to use v8 live, along with instructions for getting v8 installed if not already. IT has some mechanism for querying clients to make sure that everyone who has v6 will get v8 installed.
After a week or so, remove v6 from all the clients and turn off and delete the v6 service. Delete the v7 service and database hierarchy folder.
There are some problems, such as installing v8 will uninstall v6; in which case your v8 install must reinstate the v6 install. Be SURE to stop the Services before doing any folder copying/moving.
v8 also requires new licensing, which you would deal with before the migrate weekend.
>Louie
Before reading the thread, I replied. Apologize. Thanks a lot llandale for your reply.
License is not a problem for us, We have a valid license. We have two DB one is 8.3v Large groupand the another one is 6.0v Small group. Now, We are planning for single DB http://i.e DOORS 8.3. I am wondering where, I could download DOORS 7.0 client & server. Should I contact IBM? Thanks!
Thanks!
Murugaraj, S
|
|
Re: Migrate data from DOORS 6.0 to 8.3 llandale - Wed Mar 11 14:52:39 EDT 2009 SystemAdmin - Wed Mar 11 12:09:59 EDT 2009
Before reading the thread, I replied. Apologize. Thanks a lot llandale for your reply.
License is not a problem for us, We have a valid license. We have two DB one is 8.3v Large groupand the another one is 6.0v Small group. Now, We are planning for single DB http://i.e DOORS 8.3. I am wondering where, I could download DOORS 7.0 client & server. Should I contact IBM? Thanks!
Thanks!
Murugaraj, S
You already have a v8.3 database and you intend to merge the smaller v6 database into it? If so, forget all I just said.
You cannot merge files into an existing database hierarchy with the file system. You are going to have to archive all the projects in the v6 and restore them into the v8; you won't need v7 for that. However, you will have a serious access controls problem when you do since they are erased when you restore into a new database, and if your projects have inter-project links they will be lost.
You can eleviate the link problem by creating a new v6 project, moving all the other projects under it, then archiving that single project composed of the entire v6 database. Restore, and sort it out, then delete that now-empty v8 project.
You may want to write a script that dumps all the access records of everything in your v6 database (folders modules object etc), then manually reconstruct them in the v8 database.
|
|
Re: Migrate data from DOORS 6.0 to 8.3 SystemAdmin - Mon Mar 16 09:06:46 EDT 2009 llandale - Wed Mar 11 14:52:39 EDT 2009
You already have a v8.3 database and you intend to merge the smaller v6 database into it? If so, forget all I just said.
You cannot merge files into an existing database hierarchy with the file system. You are going to have to archive all the projects in the v6 and restore them into the v8; you won't need v7 for that. However, you will have a serious access controls problem when you do since they are erased when you restore into a new database, and if your projects have inter-project links they will be lost.
You can eleviate the link problem by creating a new v6 project, moving all the other projects under it, then archiving that single project composed of the entire v6 database. Restore, and sort it out, then delete that now-empty v8 project.
You may want to write a script that dumps all the access records of everything in your v6 database (folders modules object etc), then manually reconstruct them in the v8 database.
Thanks Louie. I just started to migrate as per your comment. I will come back if I face any issue. Thanks!
|
|
Re: Migrate data from DOORS 6.0 to 8.3 dpechacek - Thu Mar 26 08:43:59 EDT 2009
I would just go to 9.1. Otherwise you get to deal with the bugs in 8.3 that Telelogic refuses to fix due to them being fixed in the 9.x product.
The most notable for us here is the baseline creation problems where sometimes it refuses to create a baseline at the next minor revision number or it will create the baseline but the baseline creation process crashes at the end (luckily the baseline is still made and without issue).
AAI Services, Textron
dpechacek@sc-aaicorp.com
David.Pechacek@gmail.com
|
|